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1.  INTRODUCTION 


The  purpose  of  this  document  is  to  provide  a  functional  description  of  the 
Automated  Strip  Management  System  (ASMS).  ASMS  is  designed  to  be  an  improvement 
over  the  current  manual  system  of  paper  flight  data  strips,  plastic  holders,  metal  racks  and 
felt-tip  markers  now  employed  in  the  Tower  Cabs  and  TRACONS  at  major  airports.  The 
objectives  for  ASMS  include  improved  coordination  between  controllers,  a  reduction  of 
controller  workload,  and  the  automation  of  most  manual  record  keeping  procedures. 

ASMS  will  provide  position-specific  information  to  the  controller  when  he  or  she  needs  it 
in  a  manner  that  displays  the  data  in  the  most  useable  form  for  the  controller  to  accomplish 
his  or  her  job.  ASMS  will  provide  a  better  interface  with  controllers  for  data  entry  and 
transfer  than  exists  with  the  present  manual  system,  reducing  the  chance  for  errors  and 
increasing  productivity.  Additionally,  ASMS  is  intended  to  provide  the  Traffic 
Management  Unit  (TMU)  in  the  Air  Route  Traffic  Control  Center  (ARTCC)  real  time 
ground  information  suitable  for  traffic  management,  reducing  or  eliminating  the 
requirement  for  voice  communications.  N; 

In  addition  to  the  objectives  listed  above,  the  implementation  of  ASMS  at  Logan 
Tower  will  remedy  a  deficiency  in  the  existing  system  for  passing  Flight  Progress  Strip 
data  for  departing  aircraft  from  the  Tower  Cab  to  the  TRACON  located  in  an  adjacent 
building.  The  present  method  employs  a  video  camera  in  the  cab  pointed  down  at  the  rack 
of  Flight  Progress  Strips  at  the  Local  Control  position  and  two  TV  monitors  in  the 
TRACON.  As  a  result  of  reflections,  variations  in  tower  light  levels,  and  low  TV 
resolution,  this  system  has  been  judged  to  be  inadequate.  Although  solving  an  immediate 
and  serious  problem  specific  to  Boston's  Logan  Tower,  ASMS  will  be  designed  for  use  at 
any  major  tower  replacing  other  means  of  flight  data  communications  currently  employed  in 
the  ATC  system  including  voice  and  drop  tubes. 

This  document  first  describes  the  ASMS  program  and  gives  a  high  level  functional 
overview.  Next,  the  current  flight  strip  system  at  Boston  Logan  is  reviewed  and  described 
for  both  the  Tower  Cab  and  TRACON  with  emphasis  on  the  information  recorded  and 
needed  as  the  flight  strip  progresses  through  the  system.  This  includes  a  description  of  the 
aircraft  stages  (or  states)  during  the  departure  and  arrival  process  in  terms  of  information 
known  at  each  stage  (by  controller  and  aircraft)  and  possible  transfers  to  succeeding  stages 
or  states.  Finally,  the  system  requirements  are  described  in  detail  including  specific 
requirements  for  each  controller  position.  The  main  technical  challenge  for  ASMS  will  be 
the  development  of  controller  interfaces  that  provide  an  operationally  suitable  system  in  the 
Tower  cab  environment.  For  this  reason,  the  human  factors  functions  and  requirements 
have  been  separated  from  the  "information"  functions  and  requirements  in  this  document. 
The  prototype  system  will  be  designed  to  allow  changes  in  the  controller/ASMS  interface  as 
operational  experience  is  gained. 
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2.  PROGRAM  DESCRIPTION 


ASMS,  which  automates  the  handling  of  flight  strip  data,  represents  a  portion  of  the 
automation  technology  now  under  consideration  or  planned  for  the  Tower  Cab.  The 
concept  is  to  design  ASMS  as  a  stand-alone  system  that  will  bring  immediate  improvements 
to  Boston's  Logan  Tower  and  be  flexible  enough  for  incorporation  into  other  major  towers 
but  to  recognize  that  ASMS  must  be  designed  so  that  it  can  be  integrated  into  other 
automation  programs.  Specifically,  as  part  of  the  NAS  Plan  Upgrade,  the  concept  is  to 
integrate  ASMS  into  the  Airport  Surface  Traffic  Automation  (ASTA)  system  and, 
eventually,  into  the  Tower  Cab  Computer  Complex  (TCCC). 

The  purpose  of  the  Automated  Flight  Strip  Management  System  (ASMS)  is  to 
provide  electronic  flight  plan  handling  software  and  hardware  to  Boston’s  Logan  Tower. 

A  benefit  of  the  Program  will  be  to  provide  a  test  bed  for  developing  operational  concepts 
in  flight  plan  management  for  the  upcoming  Tower  Cab  Computer  Complex  (TCCC) 
Project.  The  ASMS  Program  will  also  share  a  portion  of  the  data  base,  software,  and 
hardware  that  will  be  needed  by  the  Airport  Surface  Automation  (ASTA)  Program.  ASTA 
is  an  FAA  program  for  the  development  and  application  of  advanced  surveillance, 
communications  and  automation  technologies  to  the  control  of  aircraft  and  other  vehicles  on 
the  airport  surface  with  the  objectives  of  improving  safety,  reducing  delays,  increasing 
capacity,  and  enhancing  productivity.  Initial  elements  of  the  ASTA  Program  will  be 
available  for  evaluation  as  early  as  1992  with  the  installation  of  the  new  ASDE-3  radar. 

The  Terminal  Air  Traffic  Control  Automation  (TATCA)  Program  is  also  scheduled  for 
initial  evaluation  at  Boston  Logan  starting  in  1992.  ASMS  will  provide  critical  data  to  this 
program  as  well. 
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3.  FUNCTIONAL  OVERVIEW 


The  Automated  Flight  Strip  Management  System  is  designed  to  provide  the 
following  functions: 

3.1  FLIGHT  PLAN  DATA  BASE 

The  ASMS  will  maintain  a  current  Data  Base  of  ail  flight  plans  and  amendments  for 
flights  arriving  in,  departing  from,  or  overflying  the  Boston  TRACON  airspace.  These 
will  include  flight  plans  from  the  Boston  Air  Route  Traffic  Control  Center  (ARTCC)  Host 
computer  which  comprise  flight  plans  filed  through  Automated  Flight  Service  Stations 
(AFSSs)  and  airline  "canned”  flight  plans,  and  locally  derived  flight  plans  and  amendments 
including  VFR  Terminal  Control  Area  (TCA)  arrivals  and  departures. 

3.2  INTERFACES 

ASMS  will  be  designed  to  share  the  interfaces  being  developed  for  the  Terminal  Air 
Traffic  Control  Automation  (TATCA)  Program  that  tap  data  from  the  Host  and  Automatic 
Radar  Terminal  System  (ARTS)  computers.  The  interface  with  the  Host  will  be  at  the 
Peripheral  Adapter  Module  (PAM)  in  the  Boston  ARTCC  and  will  have  access  to  messages 
being  sent  to  the  Logan  Flight  Data  Input/Output  (FDIO)  ports  in  the  Tower  and  TRACON. 
The  ARTS  interface  will  be  at  the  maintenance  display  terminal  in  the  TRACON  and  will 
provides  real  time  information  on  aircraft  (identification,  beacon  code,  type,  speed,  altitude, 
destination,  controlling  position,  and  location)  for  airplanes  being  tracked  by  the  TRACON 
radar.  This  will  include  data  on  aircraft  without  flight  plans  that  has  been  entered  directly 
into  the  ARTS  computer  by  a  controller.  The  ARTS  real  time  data  is  of  interest  primarily 
for  arriving  aircraft  to  determine  landing  sequence  and  runway  assignment  The  FDIO 
ports  have  access  through  the  Host  to  flight  plans  for  arriving,  departing,  and  overflight 
aircraft  as  well  as  General  Information  (GI)  messages.  The  GI  messages  include  Center 
Weather  Advisories  (CWAS)  such  as  Significant  Meteorological  Information  (S1GMETS), 
Airman's  Meteorological  Information  (AIRMETS),  and  terminal  forecasts,  and 
Traffic  Management  Unit  (TMU)  advisories  such  as  daily  restrictions  on  traffic  flow  to 
specific  airports. 

The  ASMS  will  be  designed  to  accommodate  interfaces  with  additional  airport 
equipment  and  status  displays  including  the  Airport  Information  Distribution  System 
(AIDS),  the  Low  Level  Wind  Shear  Aiert  System  (LLWAS),  Automatic  Weather 
Observing  System  (AWOS),  Automatic  Terminal  Information  System  (ATIS),  Systems 
Atlanta  Information  Display  (SAIDS)  computer,  Digital  Alimentary  Setting  Indicator 
(DASI),  airport  configuration  input,  runway  visual  range  (RVR)  measuring  equipment, 
runway  lighting  status,  and  the  computer  generated  airport  users  interface  line  which 
provides  general  information  between  the  airport  operator  and  user,  etc. 

3.3  HUMAN  FACTORS 

The  ASMS  will  provide  human  factors  engineered  protocols  and  entry  devices  to 
allow  for  simple  single  action  entry  of  next  logical  functions  and  to  minimize  the  need  to 
interrupt  viewing  outside  the  Tower  cab.  The  system  will  provide  CRT  display  images  and 
interfaces  customized  to  the  individual  controller  positions.  Effective  interfacing  with 
controllers  requires  that  only  the  flight  data  needed  by  the  position  be  displayed. 


3.4  OPERATIONAL  RECORDING  AND  ELIGIBILITY  FUNCTIONS 

The  ASMS  will  provide  for  a  method  of  recording  the  time  that  individual 
controllers  spend  at  each  position  and  automate  the  controller  eligibility  checking  for  each 
position.  It  will  also  provide  a  record  of  controller  training  at  a  position. 

3.5  TRAFFIC  DATA 

The  ASMS  will  provide  a  means  for  recording  traffic  data  including  Traffic  Count, 
Delay  Reporting  Data,  runway  usage  and  airport  configuration,  missed  approaches,  and 
delay  times  by  examining  real  time  data.  The  system  will  provide  for  standardized  reports. 

3.6  ARCHIVING  AND  RETRIEVAL 

The  ASMS  will  provide  for  a  system  of  archiving  and  retrieving  of  all  data  for  a 
specified  length  of  time.  Long  term  storage  will  be  provided  by  off-line  devices  but  the 
ASMS  will  have  the  capability  of  reading  data  stored  off-line.  This  will  include  the  ability 
to  retrieve  or  recreate  displays  that  were  presented  to  controllers  at  specified  times  and 
inputs  by  controllers.  The  most  likely  system  will  employ  a  removable  hard  disk  system 
for  economical  long  term  storage  and  quick  access. 

3.7  HARDWARE 

The  ASMS  will  provide  human  engineered  CRT  terminal  screens  for  each  controller 
position  interconnected  with  a  local  area  network  within  the  Tower  cab  and  include 
intrafacility  communications  connections  with  the  TRACON.  The  CRT  screens  must  be 
readily  visible  in  high  ambient  lighting  conditions.  Specifications  for  Tower  Cab  CRTs 
under  the  TCCC  contract  cannot  be  met  with  current  color  display  technology. 
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4.  CURRENT  BOSTON  FLIGHT  STRIP  SYSTEM 

This  section  describes  the  current  flight  strip  system  at  Boston's  Logan  Airport. 
First  is  a  general  discussion  of  how  flight  plans  are  entered  into  the  Air  Traffic  Control 
(ATC)  system  and  how  and  where  the  resulting  Flight  Progress  Strips  are  generated. 

Next,  the  physical  handling  and  processing  of  the  strips  is  described  for  the  Boston  Tower 
Cab  and  the  TRACON  environments.  Next  is  a  description  of  the  Flight  Progress  Strip 
itself  and  the  data  contained  on  the  strip.  Finally,  the  progress  of  a  strip  is  followed  in 
relation  to  the  progress  of  an  aircraft  through  the  various  stages  of  departure  and  arrival 
with  emphasis  on  the  information  available  to  and  input  by  the  various  controller  positions. 
This  will  set  the  stage  for  specifying  an  automated  system  ensuring  that  the  correct 
information  is  available  to  the  needed  controller  position  at  the  right  time. 

4.1  FLIGHT  PLANS  IN  THE  ATC  SYSTEM 

Flight  plans  for  flights  conducted  under  Instrument  Flight  Rules  (IFR)  or  Visual 
Flight  Rules  (VFR)  are  nominally  entered  into  the  Air  Traffic  Control  (ATC)  system 
through  Automated  Right  Service  Stations  (AFSS).  The  pilot  calls  or  visits  the  AFSS, 
receives  a  weather  briefing,  and  files  a  flight  plan  with  the  specialist.  A  flight  plan  form  is 
used  by  the  pilots  and  AFSS  specialists  to  record  the  information  and  is  reproduced  in 
Figure  1. 

For  flights  that  are  conducted  repeatedly,  such  as  scheduled  airline  flights,  the  flight 
plan  data  can  be  stored  on  computer  tape  for  automatic  entry  into  the  system.  Computer 
tapes  for  airline  flight  plans  are  kept  at  Air  Route  Traffic  Control  Centers  (ARTCC)  and 
entered  directly  into  the  Host  computer.  The  AFSSs  also  have  the  capability  of  storing 
flight  plans  on  computer  tape  and  this  is  often  done  for  standard  flight  plans  used,  for 
example,  by  air  taxis.  Right  plans  for  all  IFR  flights  and  any  VFR  flights  that  request 
services  from  ATC,  such  as  traffic  advisories,  are  entered  into  the  Host  computer  at  the 
ARTCC  serving  the  departure  airport.  The  system  of  Host  computer  determines  what 
ARTCCs  will  be  controlling  the  flight  and  will  transmit  the  flight  plan  data  to  the 
succeeding  controlling  ARTCC  as  the  flight  progresses.  These  Host  computer  generates 
Right  Progress  Strips  through  Right  Data  Input/Output  (FDIO)  primers  at  controlling 
facilities.  Controllers  can  also  use  the  FDIO  to  manually  input  flight  plans.  VFR  flights 
not  requesting  services  are  not  entered  into  the  Host  computer.  The  flight  plan  process  is 
illustrated  in  Figure  2. 

Any  flight  plan  filed  at  any  AFSS  or  entered  from  computer  tape  or  manually  at  any 
Center  that  enters  into  the  system  of  Host  computers,  as  described  above,  for  a  flight  that 
will  depart,  arrive  or  fly  through  airspace  controlled  by  Boston  Center,  will  be  transferred 
to  the  Host  computer  at  Boston  ARTCC  in  Nashua,  New  Hampshire.  The  Host  computer 
at  Nashua  will  determine  which  of  these  flights  will  use  airspace  controlled  by  Boston 
TRACON.  The  airspace  controlled  by  Boston  TRACON  is  defined  in  a  letter  of  agreement 
between  Boston  TRACON  and  Boston  Center  and  generally  includes  airspace  within 
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approximately  thirty  miles  of  Logan  airport  up  to  approximately  fourteen  thousand  feet  plus 
some  lower  "shelves"  incorporating  satellite  airports  and  transition  airspace.  At  a 
predetermined  adjustable  time  (usually  thirty  minutes)  before  departure,  a  Flight  Progress 
Strp  is  sent  to  the  Boston  Tower  and  either  printed  in  the  Tower  cab  or  TRACON.  Flight 
strips  for  aircraft  departing  from  Logan  are  printed  on  the  FDIO  printer  in  the  Tower  Cab. 
Flight  strips  for  aircraft  departing  from  satellite  airports  or  overflights  within  Boston 
TRACON  boundaries  are  printed  in  the  TRACON.  Flight  progress  information  for  aircraft 
arriving  at  Logan  or  satellite  airports  is  also  available  from  the  Boston  ARTCC  Host 
computer  but,  as  described  below,  is  not  always  printed  in  the  form  of  a  Flight  Progress 
Strip. 


Data  for  VFR  aircraft  that  file  a  flight  plan  and  request  ATC  radar  services  are  also 
available  in  the  Host  computer.  Flight  data  for  VFR  aircraft  arriving  and  departing  from 
Logan  or  transiting  the  Boston  Terminal  Control  Area  (TCA)  that  have  not  filed  a  flight 
plan  is  input  into  the  ARTS  computer  by  a  controller  but  no  Flight  Progress  Strip  is 
generated  and  the  data  is  not  received  by  the  Host  computer.  The  Flight  Data  position  in 
Boston  Tower  will  insert  the  flight  information  into  the  ARTS  for  a  VFR  flight  departing 
Logan.  This  data  includes  the  aircraft  identification,  aircraft  type,  requested  altitude, 
direction  of  flight,  and  a  single  letter  designation  code  indicating  the  departure  control 
sector  that  will  handle  the  flight  initially.  For  VFR  arrivals,  the  data  is  entered  by  the 
approach  control  position  that  first  works  the  aircraft  and  gives  the  clearance  into  the  TCA. 
The  data  includes  the  aircraft  identification  and  type  but  will  not  generally  include  the 
altitude  since  it  appears  on  the  Mode  C  readout  in  the  data  tag.  The  destination  airport  is 
included  and  will  appear  on  the  data  tag. 

4.2  FLIGHT  PROGRESS  STRIP  DESCRIPTION 

The  Flight  Progress  Strip,  depicted  in  Figure  3,  differs  slightly  from  the  Flight 
Progress  Strips  used  by  En  Route  Centers  although  the  differences  are  not  important  and 
ASMS  is  concerned  with  terminal  Right  Progress  Strips.  The  strip  of  paper  is 
approximately  8  inches  long  by  1  inch  wide  with  perforations  on  the  long  edges  so  that  the 
strips  can  be  separated  after  being  printed  on  the  FDIO  printer.  There  are  plastic  holders 
available  in  the  TRACON  and  Tower  that  are  sized  to  hold  the  strip  and  fit  into  a  vertical 
rack  to  facilitate  reordering  of  the  strips.  The  data  that  appears  on  a  Right  Progress  Strip 
depends  on  whether  it  is  for  an  arrival,  departure,  or  overflight.  The  numbers  on  the  strip 
in  Figure  3  are  called  data  blocks.  Table  1  lists  the  data  recorded  in  the  data  blocks  depicted 
on  the  strip  for  the  three  categories  of  aircraft.  Table  2  is  a  list  of  the  aircraft  equipment 
suffix  codes  used  in  block  3  appearing  after  the  designation  for  the  type  of  aircraft. 

Tables  3  and  4  list  clearance  and  miscellaneous  abbreviations  approved  for  use  by 
controllers. 
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Figure  3.  Illustration  of  Terminal  Flight  Progress  Strip 
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TABLE  1 


Terminal  Flight  Progress  Strip  Data 


Data  Block 

Arrivals 

Departures 

Overflights 

1 

Aircraft  Identification 

2 

Revision  number  (FDEP  locations  only). 

2A 

Strip  request  originator.  (At  FDEP  locations  this  indicates 
the  sector  or  position  that  requested  a  strip  be  printed). 

3 

Number  ol  aircraft  if  more  than  one,  heavy  aircraft  indicator  *HT 
if  appropriate,  type  of  aircraft,  and  aircraft  equipment  suffix. 

4 

Computer  identification  number  if  required. 

5 

Secondary  radar  (beacon)  code  assigned. 

6 

Previous  fix  (FDEP  loca¬ 
tions)  or  inbound  airway. 

Proposed  departure  time. 

Coordination  fix. 

7 

Coordination  fix. 

Requested  altitude. 

Overflight  coordination 
indicator 

(FDEP  locations  only). 

8 

Estimated  time  of  arrival 
at  the  coordination  fix  or 
destination  airport. 

Departure  airport 

Estimated  time  of  arrival 
at  the  coordination  fix. 

9 

Altitude  (in  hundreds  of  feet) 
and  remarks. 

Machine  generated  - 
Route,  destination,  and  re¬ 
marks.  Manually  enter  alti¬ 
tude/altitude  restrictions  in 
the  order  flown  if  appropriate. 
Manually  prepared  - 
Clearance  limit,  route,  altitude 
/altitude  restrictions  in  the  or¬ 
der  flown,  if  appropriate,  and 
remarks. 

Altitude  and  route  of  flight 
through  the  terminal  area. 

9A 

Destination  airport/point  out 
/radar  vector/speed  adjust¬ 
ment  information.  Air  Traffic 
managers  may  authorize  the 
omission  of  any  of  these  items 
if  no  misunderstanding  will  re¬ 
sult,  and  they  may  authorize 
the  optional  use  of  spaces 

2A  and  10-18  for  point  out 
/radar  vector  or  speed  ad¬ 
justment  information. 

Point  out/radar  vector/speed  adjustment  information. 

Air  Traffic  managers  may  authorize  the  optional  use  ol 
spaces  2A  and  10-16  for  this  information. 

10-18 

Enter  data 

Radar  facility  personnel 
need  not  enter  data  in  these 
spaces  except  when  non- 
radar  procedures  are  used 
or  when  radio  recording 
equipment  is  inoperative. 

>  as  specified  by  a  facility  direc 
Items  such  as  departure 
time,  runway  used  for  take¬ 
off,  check  marks  to  indi¬ 
cate  information  forwarded 
or  relayed, may  be  entered 
in  these  spaces. 

live. 
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TABLE  2 

Aircraft  Equipment  Suffix  in  Data  Block  3. 


Suffix  Meaning 


/A .  DME,  transponder  with  altitude  encoding  capability. 

/B .  DME,  transponder  with  no  altitude  encoding  capability. 

/C .  RNAV,  transponder  with  no  altitude  encoding  capability. 

/D .  DME,  no  transponder. 

/M .  TACAN-only,  no  transponder. 

/N .  TACAN-only,  transponder  with  no  altitude  encoding  capability. 

/ P .  TACAN-only,  transponder  with  altitude  encoding  capability. 

/R .  RNAV,  transponder  with  altitude  encoding  capability. 

/ T .  Transponder  with  no  altitude  encoding  capability. 

/U .  Transponder  with  altitude  encoding  capability. 

/W .  RNAV  and  no  transponder. 

/X .  No  transponder. 
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TABLE  3 


Flight  Progress  Strip  Clearance  Abbreviations 


Abbreviation _ Meaning 


A .  Cleared  to  airport  (point  of  intended  landing). 

B .  Center  clearance  delivered. 

C .  ATC  clears  (when  clearance  relayed  through  non-ATC  facility). 

CAF .  Cleared  as  filed. 

D .  Cleared  to  depart  from  the  fix. 

F .  Cleared  to  the  fix.. 

FI .  Cleared  to  hold  and  instructions  given. 

L .  Cleared  to  land. 

N .  Clearance  not  delivered. 

O .  Cleared  to  the  outer  marker. 

PD .  Cleared  to  climb/descend  at  pilot's  discretion. 

Q .  Cleared  to  fly  specified  sectors  of  a  NAVAID  defined  in  terms  of 

courses,  bearings,  radials  or  quadrants  within  a  designated 
radius. 

T .  Cleared  through  (for  landing  and  takeoff  through  intermediate 

point). 

V .  Cleared  over  the  fix. 

X .  Cleared  to  cross  (airway,  route,  radial)  at  (point). 

Z .  Tower  jurisdiction. _ 
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TABLE  4 


Flight  Progress  Strip  Miscellaneous  Abbreviations 


Abbreviation _ Meaning 


B  C .  Back  course  approach. 

CT .  Contact  approach. 

FA .  Final  approach. 

I .  Initial  approach. 

ILS .  ILS  approach. 

M  A .  Missed  approach. 

MLS .  MLS  approach. 

NDB .  Nondirecdonal  radio  beacon  approach. 

OTP .  VFR  conditions  on-top. 

PA .  Precision  approach. 

PT .  Procedure  turn. 

RH .  Runway  heading. 

RP .  Report  immediately  upon  passing  (fix/altitude). 

RX .  Report  crossing. 

SA .  Surveillance  approach. 

SI .  Straight -in  approach. 

TA .  TACAN  approach. 

TL .  Turn  left. 

TR .  Turn  right. 

VA .  Visual  approach. 

VR .  VOR  approach. _ 
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4.3  USE  OF  FLIGHT  PROGRESS  STRIPS  AT  BOSTON 

The  follov.  ing  sections  detail  the  use  of  Flight  Progress  Strips  in  the  Boston 
facility.  Figure  4  is  included  as  a  summary  guide  to  the  detailed  descriptions  of  sections 

4.3.1  and  4.3.2. 

4.3.1  Use  of  Flight  Progress  Strips  in  the  Logan  Tower  Cab 

The  Boston  Tower  receives  Right  Progress  Strips  for  all  IFR  departures  from 
Logan  airport  from  the  Boston  ARTCC  Host  computer.  They  are  printed  on  the  FDIO 
printer  located  at  the  Right  Data  controller  position  in  the  back  of  the  cab  in  the  northwest 
comer.  The  strips  are  passed  clockwise  around  the  cab  to  the  appropriate  controller 
positions  as  described  in  the  sections  below.  The  strips  are  normally  placed  in  plastic 
holders  that  fit  in  trays  so  that  the  strips  are  ordered  vertically.  Right  information  for  VFR 
departures  is  handwritten  on  blank  strips  by  the  Clearance  Delivery  position.  The  Flight 
Data  Controller  will  request  a  discrete  beacon  code  for  VFR  aircraft  from  the  ARTS 
computer  by  typing  in  the  call  sign,  direction  of  flight,  altitude,  and  controller  position  that 
will  be  working  the  aircraft.  That  data,  now  in  the  ARTS  computer,  will  be  available  for 
the  correct  departure  position  in  the  TRACON.  The  Right  Progress  Strips,  both  the 
printed  IFR  strips  and  the  handwritten  VFR  strips,  will  eventually  progress  to  the  Local 
Controller  (tower)  position  arranged  vertically  on  a  tray.  A  video  camera,  positioned  above 
the  Local  Controller  and  looking  down  at  the  flight  strip  rack,  provides  a  video  image  of 
departure  flight  strips  for  display  on  monitors  in  the  TRACON.  The  images  are  sometimes 
difficult  to  read  because  of  focusing  problems,  changing  light  conditions  in  the  Tower  Cab, 
and  shadows  or  hands  of  controllers  that  fall  in  the  field  of  view. 

The  Tower  Cab  does  not  print  Right  Progress  Strips  for  arrival  aircraft  although  the 
information  is  available  in  the  Host  computer  in  Boston  Center.  The  assistant  Local 
Controller  will  hand  write  the  inbound  flight  numbers  on  a  blank  strip  (the  back  of  a 
pre-printed  strip  form)  using  the  data  available  from  the  ARTS. 

4.3.2  Use  of  Right  Progress  Strips  in  Boston  TRACON 

Right  Progress  Strips  for  aircraft  departing  Logan  are  not  printed  in  the  TRACON. 
Departure  information  from  the  Flight  Progress  Strips  in  the  Tower  Cab  is  displayed  on 
television  monitors  at  the  two  TRACON  positions  that  initially  control  departures  from 
Logan.  This  allows  the  departure  controller  to  see  the  additional  current  information 
concerning  the  flights  that  is  handwritten  on  the  strips  by  the  Tower  controllers.  It  also 
ensures  that  the  departure  controllers  know  the  departure  sequence.  This  system  has 
proven  inadequate  because  of  monitor  readability  problems  described  above. 

The  Boston  TRACON  has  a  RDIO  printer  located  at  the  Satellite  Right  Data 
Controller  position.  Flight  Progress  Strips  for  aircraft  departing  from  satellite  airports  are 
routed  to  this  position  from  the  Host  computer  at  Boston  ARTCC.  Strips  for  overflights 
through  Boston  TRACON  airspace  are  also  routed  by  the  Host  to  this  position.  The  Host 
also  routes  Right  Progress  Strips  for  aircraft  departing  from  satellite  airports  directly  to 
FDIO  printers  in  the  satellite  towers.  For  satellite  towers  that  do  not  have  FDIO  printers, 
data  on  the  Flight  Progress  Strips  is  read  over  land-lines  (telephones)  to  the  Clearance 
Delivery  position  in  the  satellite  tower  by  the  Satellite  Right  Data  Controller  in  Boston 
ARTCC.  The  Flight  Progress  Strips  for  overflights  transiting  Boston  TRACON  airspace 
are  handed  by  the  Right  Data  controller  to  the  controller  position  that  will  first  handle  the 
aircraft. 
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Figure  4.  Use  of  Flight  Progress  Strips  in  Boston  logon  Airport 


The  Boston  TRACON  is  unlike  most  other  major  TRACONS  in  that  it  does  not  use 
arrival  Flight  Progress  Strips  for  traffic  landing  at  Logan.  This  is  because  the  ARTS  data 
tag  contains  the  arrival  airport  designation  (no  designation  tag  means  Logan)  and  all 
necessary  information  about  the  aircraft  This  is  a  local  ARTS  software  modification 
known  as  a  patch.  Flight  Progress  Strips  for  satellite  arrivals  are  provided  to  the  Satellite 
Controller.  VFR  aircraft  arriving  at  satellite  airports  and  requesting  services  are  given  the 
appropriate  frequency  for  the  control  position  responsible  for  that  airspace  and  assigned  a 
discrete  beacon  code  by  that  controller.  No  flight  strip  information  is  entered  into  the 
system.  VFR  aircraft  landing  at  Logan  or  transiting  the  TCA  are  also  assigned  a  discrete 
beacon  code  and  a  "short"  strip  is  prepared  in  the  Tower  Cab  as  described  above. 

4.4  FLIGHT  STAGES  AND  THE  PROCESSING  OF  FLIGHT  PROGRESS 
STRIPS 

Departing  and  arriving  aircraft  proceed  through  certain  stages  or  states  during  the 
departure  or  arrival  process  and  the  Flight  Progress  Strips  move  with  them.  At  each  stage 
there  is  information  known  to  the  controller  and/or  pilot  necessary  to  describe  that  stage. 
Additional  steps  must  be  taken  to  transfer  the  aircraft  to  a  succeeding  stage.  The  purpose  of 
this  section  is  to  carefully  describe  each  of  the  aircraft  stages  with  particular  attention  to 
a)  information  needed  by  the  controlling  position,  b)  Right  Progress  Strip  status  as  a 
function  of  aircraft  stage,  and  c)  the  transfer  of  flight  strip  information. 

4.4.1  Departing 

As  an  aircraft  depans  from  Boston  Logan  airport,  its  Right  Progress  Strip  proceeds 
from  one  controller  position  to  the  next.  Figure  5,  at  the  end  of  this  section,  illustrates  the 
tie-in  between  the  progress  of  an  aircraft  through  the  departure  sequence  with  the 
concurrent  progress  of  its  Right  Progress  Strip.  In  all,  the  Flight  Progress  Strip  is  handled 
by  six  different  positions  in  Logan  Tower.  Each  position  makes  a  different  use  of  the 
Strip.  Depending  on  traffic  intensity,  some  of  the  positions  may  be  "combined,"  that  is  one 
person  may  perform  the  functions  of  two  or  more  controllers. 

4.4. 1 . 1  Aircraft  at  Gate  without  Clearance 

Airline  aircraft  parked  at  a  gate  normally  have  a  published  scheduled  departure  time 
and  destination.  A  "canned"  flight  plan  stored  on  a  computer  tape  and  conforming  to  airline 
and  FAA  requirements  is  automatically  entered  into  the  Host  computer  at  Boston  Center  in 
Nashua,  New  Hampshire  and  a  Right  Progress  Strip  is  printed  at  the  FDIO  in  the  Logan 
Tower  Cab  at  least  thirty  minutes  prior  to  the  proposed  departure  time.  The  pilots  will  get  a 
copy  of  this  flight  plan  from  their  company.  If  the  planned  flight  is  not  on  computer  tape, 
then  it  will  have  to  be  filed  through  an  Automated  Right  Service  Station  (AFSS)  or  entered 
directly  into  the  Host  by  a  Right  Data  position.  Depending  on  the  length  of  the  flight,  there 
may  be  more  than  one  "standard"  flight  route  that  complies  with  FAA  preferred  route 
requirements.  The  pilot's  choice  of  route  and  altitude  will  depend  on  weather  and  winds 
aloft  as  well  as  gross  weight.  For  major  airlines  and  most  operators  of  large  transport 
aircraft,  all  flights  are  conducted  under  instrument  flight  rules  (IFR)  regardless  of  the 
weather  because  the  aircraft  fly  at  altitudes  that  require  an  IFR  clearance  (in  positive  control 
airspace  above  18,000  feet  mean  sea  level)  and/or  it  is  company  policy.  Some  commuter 
flights  are  conducted  VFR  and  it  is  legal  for  a  large  airline  transport  to  file  VFR  below 
positive  controlled  airspace  but  this  is  not  normally  done  in  the  Boston  airspace. 
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Figure  5.  Flight  Progress  Strip  Flow  for  Departure  Aircraft  at  Boston  Logan  Airport 


Alternatively,  the  pilot  may  file  an  IFR  or  VFR  flight  plan  directly  through  an 
Automated  Flight  Service  Station  and  this  plan  will  be  entered  in  the  computer  with  the 
same  status  as  those  entered  from  computer  tape.  This  can  be  done  a)  in  person  at  the 
Automated  Flight  Service  Station  facility,  b)  by  phone  either  through  the  briefer  or 
specialist  or  via  special  answering  machines  that  record  flight  plans  read  by  the  pilot,  or 
c)  air  Filed  with  a  specialist  over  the  air  to  ground  frequency.  Any  ATC  facility,  time 
permitting,  can  process  a  request  for  filing  a  flight  plan  and/or  an  instrument  clearance. 
Instrument  clearances  or  clearances  to  enter/exit/transit  the  Boston  Terminal  Control  Area 
(TCA)  can  be  issued  by  the  controlling  facility  without  the  pilot  having  to  File  a  flight  plan. 
These  requests  are  made  by  the  pilot  to  the  controlling  facility  over  the  appropriate  air  to 
ground  frequency. 

Every  flight  plan  in  the  Host  computer  has  a  computer  identification  number  and  a 
revision  number  (if  die  flight  plan  is  amended)  that  is  assigned  by  the  computer  and  stays 
with  the  flight  plan  and  is  printed  on  every  Flight  Progress  Strip  at  all  facilities  that  handle 
the  flight.  The  computer  does  not  automatically  examine  the  requested  routing  to  check  for 
compliance  with  current  ATC  traffic  procedures.  This  is  done  by  the  Flight  Data  positions 
at  the  initial  controlling  facilities.  The  Flight  Data  positions  in  the  Tower  Cab  at  Logan  and 
at  Boston  Center  in  Nashua  will  examine  the  routing  and  make  amendments  as  necessary. 
They  will  also  ensure  that  the  routing  conforms  with  agreements  with  neighboring  Centers 
(and  TRACONS  for  aircraft  operating  under  the  Tower  En  Route  Control  program) 
confirming  routing  over  the  telephone  if  necessary.  Nevertheless,  at  times  flight  plan 
routes  are  filed  and  cleared  that  do  not  confirm  with  procedures  and  routings  used  by 
subsequent  control  facilities  and  this  requires  en  route  amendments.  Any  amendments  or 
changes  which  result  in  a  routing  different  than  that  requested  by  the  pilot  in  his  flight  plan 
trigger  the  appearance  of  the  code  "FRC"  on  the  Flight  Progress  Strip  which  stands  for 
"Full  Route  Clearance."  This  indicates  that  the  Clearance  Delivery  position  should  read  the 
full  routing  to  the  pilot  instead  of  using  the  abbreviated  "cleared  as  filed"  terminology  when 
reading  the  clearance. 

The  flight  strip  with  the  requested  altitude  and  routing  is  printed  in  the  Logan  Tower 
Cab  and  at  the  first  en  route  sector  of  the  Boston  Center  approximately  thirty  minutes 
before  the  requested  departure  time.  The  Flight  Data  position  removes  the  strip  from  the 
printer  and  checks  the  flight  plan  route  for  conformance  with  local  traffic  flow  procedures 
and  with  handoff  agreements  with  neighboring  facilities.  If  there  are  any  doubts  or 
questions,  the  Flight  Data  Controller  will  call  the  succeeding  facilities  to  verify  the  routing. 
The  Flight  Data  Controller  must  also  coordinate  and  record  any  delays  or  flow  restrictions. 
The  ATC  system  can  impose  departure  delays  due  to  flow  control  or  en  route  spacing. 
Central  Flow  has  a  computer  program  that  estimates  congestion  at  specific  airports  and 
imposes  ground  delays  for  departing  aircraft  bound  for  the  congested  airports.  These 
delays  are  imposed  by  specifying  Estimated  Departure  Clearance  Times  (EDCTs).  The 
Traffic  Management  Coordinator  (TMC)  at  the  Traffic  Management  Unit  (TMU)  in  the 
Boston  ARTCC  relays  the  EDCT  times  to  the  airports  via  the  Flight  Progress  Strip.  In 
addition,  the  TMC  can  issues  delays  as  pan  of  the  En  Route  Spacing  Program  (ESP)  to 
control  traffic  flow  within  Boston  Center.  ESP  spacing  delays  are  imposed  to  meet 
handoff  metering  requests  (expressed  as  miles  in  trail  or  aircraft  per  time  unit)  from 
neighboring  Centers  or  TRACONS.  The  Flight  Data  Controller  can  consult  one  of  the 
Systems  Atianta  Information  Display  pages  to  determine  which  airports  have  current  flow 
control  or  en  route  spacing  restrictions.  The  EDCTs  and  ESP  delays  are  recorded  in  box  8 
on  the  Flight  Progress  Strips. 
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After  confirming  the  routing  and  coordinating  and  recording  any  delays  or  flow 
control  restrictions,  the  Flight  Data  Controller  puts  the  Flight  Progress  Strip  into  a  plastic 
holder  and  places  it  in  one  of  two  rows  in  front  of  the  Clearance  Delivery  position.  It  will 
remain  in  this  position  until  the  pilot  requests  his  ATC  clearance  from  Clearance  Delivery. 
An  IFR  flight  plan  will  "time  out"  after  two  hours  unless  a  request  is  made  to  keep  it  active 
to  accommodate  a  delay.  The  length  of  time  the  flight  plan  will  be  held  can  be  extended  in 
the  event  of  delays  but  is  limited  by  the  ARTS  capacity. 

The  pilots  must  also  receive  a  weather  briefing  before  departure,  either  through  their 
company's  weather  department  or  from  the  FAA.  Airline  flights  must  also  obtain  a 
clearance  from  their  company  dispatch  office  before  departure.  The  dispatcher  checks, 
among  other  things,  weight  and  balance,  fuel,  runway  length  requirements,  conformance 
with  required  maintenance,  and  the  filed  route.  Weight  and  balance  data  is  used  to  calculate 
aircraft  takeoff  and  climb  performance  including  Vi,  Vr,  and  V2  (the  velocities  at  which 
the  aircraft  can  continue  the  take-off  in  the  event  of  engine  failure,  the  velocity  at  rotation, 
and  the  velocity  at  lift-off  respectively).  Sometimes  the  aircraft  will  depart  the  gate  without 
having  "the  numbers"  from  its  dispatch  office  and  will  receive  the  numbers  and  clearance 
from  dispatch  over  its  company  ARINC  radio  frequency.  If  the  aircraft  departs  the  gate 
and  enters  the  taxiway  queue  and  then  fails  to  receive  a  clearance  from  the  dispatcher,  it  will 
have  to  return  to  the  gate. 

4.4. 1 .2  Clearance  Delivery 

Historically,  RFR  clearances  have  been  read  to  pilots  over  the  Ground  Control 
frequency,  and  at  many  less  busy  airports  this  is  still  the  case.  Congestion  of  the  Ground 
Control  frequency  at  Logan  and  other  busy  airports,  however,  has  dictated  the  use  of  a 
separate  frequency  known  as  pre-taxi  Clearance  Delivery  or  simply  Clearance  Delivery. 
This  frequency,  published  on  approach  procedure  charts,  is  used  by  the  pilot  to  request  his 
or  her  ATC  clearance  prior  to  engine  start  or  "push-back"  from  the  gate.  Clearance 
Delivery  is  a  separate  position  at  major  airports  and  the  function  of  the  Clearance  Delivery 
controller  is  to  read  the  ATC  clearance  to  the  pilot  and  monitor  the  "read-back"  for 
accuracy. 

The  clearance  itself  consists  of  the  initial  and  en  route  routing  (which  may  include  a 
published  Standard  Instrument  Departure  or  SED  procedure  ),  initial  altitude  and  an 
expected  altitude  clearance  (along  with  a  time  or  distance  in  which  to  expect  the  higher 
altitude),  a  four-digit  beacon  or  "squawk"  code  for  the  transponder,  and  a  frequency  for 
departure  control.  The  portions  of  the  clearance  preceded  by  "expect"  are  given  so  that  the 
pilot  will  follow  those  altitudes/routings  in  the  event  of  lost  communications.  Since  most 
of  the  major  airline  flight  plans  are  stored  on  computer  tapes  and  presumably  follow 
customary  ATC  routings,  it  is  usual  for  the  route  Filed  to  be  approved  and  the  route  portion 
of  the  clearance  to  be  read  "cleared  as  filed"  or  contain  some  initial  vectors/routings  and 
read  "and  then  as  filed"  with  the  pilot  having  the  responsibility  for  knowing  what  route  was 
requested.  The  Clearance  Delivery  position  knows  to  read  the  entire  routing  to  the  pilot  if 
the  code  letters  "FRC"  which  stand  for  "Full  Route  Clearance"  appear  on  the  Flight 
Progress  Strip.  This  is  indicative  of  a  change  in  the  routing  from  that  filed  in  the  flight 
plan.  A  readback  of  the  entire  clearance  by  the  pilot  is  customary  to  ensure  accuracy, 
especially  of  the  beacon  code,  initial  altitude/heading,  and  departure  control  frequency.  At 
very  busy  airports,  including  Logan,  frequency  congestion  sometimes  makes  it  impractical 
for  a  complete  readback,  and  it  has  become  a  common  practice  to  abbreviate  the  readback  to 
essential  information  with  the  beacon  code,  initial  altitude  and  departure  frequency  numbers 
being  a  minimum  if  the  route  is  as  filed. 
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When  the  Clearance  Delivery  controller  finishes  reading  the  clearance  and 
monitoring  the  readback,  he  or  she  passes  the  Flight  Progress  Strip  to  the  Gate  Hold 
position  known  as  "Boston  Gate"  who  puts  it  in  a  stack  of  aircraft  that  will  be  in  queue  for 
taxiing.  The  aircraft  now  has  a  clearance  with  ATC  which  is  good  from  that  moment  until 
whenever  the  aircraft  eventually  makes  it  to  the  runway  and  is  cleared  for  takeoff.  Ground 
delays  encountered  as  a  result  of  taxiway  or  runway  queues  are  not  "explained"  to  those 
members  of  the  ATC  team  who  control  die  aircraft  after  departure;  the  subsequent 
controllers  simply  see  the  upcoming  Flight  Progress  Strip  as  the  aircraft  enters  their 
airspace.  Flight  Progress  Strips  are  printed  at  the  appropriate  controlling  facilities  along  the 
route  based  on  the  recorded  departure  time  and  updated  actual  and  estimated  times  at  en 
route  fixes. 

4.4. 1.3  Boston  "Gate" 

Clearance  Delivery  will  instruct  the  airplane  to  contact  "Boston  Gate"  on  the 
appropriate  frequency  or  to  monitor  Ground  Control  depending  on  the  current  traffic  at 
Logan.  The  function  of  Boston  Gate  is  to  assist  Ground  Control  in  the  sequencing  of 
departing  aircraft.  This  reduces  the  number  of  aircraft  waiting  on  the  taxiway  with  engines 
running  and  reduces  frequency  congestion  on  the  Ground  Control  channel  when  traffic  is 
heavy  and  there  are  a  lot  of  aircraft  waiting  for  taxi  clearance.  En  Route  metering 
requirements  of  neighboring  sectors  effect  the  sequencing  of  departing  aircraft  Since 
aircraft  in  the  queue  on  the  taxiway  cannot  be  easily  resequenced,  the  Boston  Gate  position 
assists  in  the  taxiway  sequencing  by  coordinating  the  order  in  which  aircraft  "push  back" 
with  Ground  Control.  The  Flight  Data  position  receives  a  daily  restriction  list  from  the 
TMU  over  the  GI  interface  with  the  Boston  ARTCC  Host  computer.  Restrictions,  typically 
expressed  as  limits  (miles-in-trail)  at  departure  fixes,  are  recorded  in  box  8  on  the  Flight 
Progress  Strip  of  affected  aircraft  by  the  Flight  Data  position.  Boston  Gate  organizes  the 
pool  of  Flight  Progress  Strips,  visible  to  the  Ground  Control  position,  to  facilitate 
sequencing  the  taxiway  queue  to  meet  in-flight  departure  restrictions.  Boston  Gate  will 
update  the  ESP  and  EDCT  times  on  the  Flight  Progress  Strip  as  that  information  is 
received.  The  Flight  Progress  Strip  is  transferred  to  the  stack  in  front  of  the  Ground 
Control  position  as  he/she  requests  flights  that  are  ready  and  meet  the  departure  fix  criteria. 

When  aircraft  contact  Boston  Gate,  they  are  instructed  to  call  back  when  they  are 
ready  to  start  their  engines.  Boston  Gate  will  inform  the  flight  of  any  expected  delay 
imposed  by  Central  Flow  or  the  ARTCC.  After  any  delay,  Boston  Gate  will  tell  the  pilot  to 
monitor  the  Ground  Control  frequency  for  taxi  clearance.  The  aircraft  do  not  contact 
Ground  Control  but  monitor  the  frequency  until  they  are  called.  When  Ground  Control  is 
ready  to  authorize  "push  back,"  the  controller  will  call  the  flight  directly.  Airline  employee 
ramp  controllers  are  responsible  for  aircraft  at  the  gate  and  will  monitor  the  aircraft  during 
the  push-back  and  engine  start  procedures. 

Although  Ground  Control  authorizes  "push  back,"  the  liability  for  proper 
separation  from  other  aircraft  still  lies  with  the  airline  and  private  gate  controllers  at  this 
point.  Theoretically,  the  aircraft  could  "push  back"  at  any  time  and  even  taxi  as  long  as  it 
remained  clear  of  the  active  taxiways.  As  a  practical  matter,  traffic  grid  locks  would  occur 
in  the  gate  area,  so  aircraft  do  not  depart  from  the  gate  until  cleared.  The  airlines  however 
retain  responsibility  for  taxi  collision  avoidance  until  the  airplane  is  in  the  "movement  area." 
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4.4. 1.4  Taxiing 


Aircraft  receive  clearance  to  "push  back"  and  taxi  to  the  departure  runway  from  the 
Ground  Control  controller  position.  Once  an  aircraft  crosses  into  die  "movement  area"  it  is 
under  the  jurisdiction  of  Ground  Control.  The  nominal  division  of  responsibility  between 
Ground  Control  and  the  Tower,  as  described  in  the  Airman’s  Information  Manual,  is  for 
Ground  Control  to  control  aircraft  on  the  ground  until  they  are  ready  for  departure.  The 
Local  Controller  controls  the  active  runways  for  arriving  and  departing  aircraft.  The 
Ground  Control  position  must  coordinate  crossings  of  the  active  runways  with  the  Local 
Controller.  Permission  for  the  pilot  to  cross  runways,  including  active  runways,  is  implicit 
in  the  clearance  to  taxi  to  an  active  runway  given  by  Ground  Control  unless  specifically 
prohibited  by  the  use  of  instructions  to  "hold  short"  of  a  runway.  From  paragraph  241  a. 
(5)  of  the  Airman's  Information  Manual: 

When  ATC  clears  an  aircraft  to  "taxi  to"  an  assigned  takeoff 
runway,  the  absence  of  holding  instructions  authorizes  the  aircraft  to 
"cross"  all  runways  which  the  taxi  route  intersects  except  the 
assigned  takeoff  runway.  It  does  not  include  authorization  to  "taxi 
onto"  or  "cross"  the  assigned  takeoff  runway  at  any  point.  In  order 
to  preclude  misunderstandings  in  radio  communications,  ATC  will 
not  use  the  word  "cleared"  in  conjunction  with  authorization  for 
aircraft  to  taxi. 

Boston  Logan  follows  this  convention  and  the  Ground  Controller  must  coordinate 
with  the  Local  Controller  any  time  an  aircraft  crosses  an  active  runway.  The  use  of  "hold 
short"  instructions  is  common.  There  can  be  more  than  one  active  runway  depending  on 
the  airport  configuration.  The  airport  configuration,  in  turn,  depends  on  the  surface  winds, 
noise  abatement  procedures,  and  traffic.  A  given  airport  configuration  has  certain  runways 
used  for  departures,  arrivals  or  both.  For  a  given  airport  configuration  all  runways  in  use 
are  considered  active  regardless  of  the  "rate"  of  use  of  that  runway.  It  is  possible  for  an 
aircraft  to  use  a  runway  that  is  not  considered  active  for  the  airport  configuration  in  effect 
at  the  time.  For  example,  the  primary  departure  runway(s)  may  be  too  short  for  an  aircraft 
in  the  heavy  category  or  a  high  performance  military  jet  fighter.  In  that  case  the  aircraft  can 
be  cleared  to  takeoff  on  a  longer  runway  after  coordination  with  the  departure  controller. 
Coordination  with  departure  would  not  be  required  if  the  runway  was  considered  an  active 
runway  for  the  airport  configuration.  In  point  of  fact,  any  runway  can  be  requested  by  a 
pilot  for  take-off  or  landing  in  any  direction,  regardless  of  the  airport  configuration  ,  but  as 
a  practical  matter  such  a  request  could  result  in  a  long  delay.  It  is  the  pilot's  responsibility 
to  ensure  that  the  runway  assigned  is  adequate  for  the  performance  of  his  or  her  airplane. 

4.4. 1.5  Take-Off 

After  an  aircraft  has  crossed  all  active  runways  on  its  taxi  route  and  is  approaching 
the  end  of  the  departure  runway  it  will  be  instructed  by  Ground  Control  to  monitor  the 
Tower  frequency.  When  departure  traffic  is  high,  there  will  be  a  queue  at  the  end  of  the 
departure  runway.  Aircraft  will  continue  to  monitor  the  Tower  frequency  while  in  the 
queue.  As  aircraft  enter  the  queue,  the  Ground  Controller  transfers  the  Flight  Progress 
Strips  to  the  Local  Controller  in  sequence.  This  is  the  stack  that  is  viewed  on  the  television 
monitors  in  the  TRACON.  If  the  aircraft  is  going  to  use  a  runway  other  than  a  primary 
departure  runway,  this  will  be  coordinated  with  the  departure  controller  in  the  TRACON 
and  written  on  the  Flight  Progress  Strip.  Aircraft  do  not  contact  the  Tower  when  they  are 
ready  to  take-off.  Instead,  the  Local  Controller  knows  the  aircraft  identification  and  call 
signs  by  virtue  of  their  Flight  Progress  Strips  and  will  contact  the  aircraft  directly  as  they 
become  first  in  line.  When  there  is  more  than  one  primary  runway  in  use  for  departures. 
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the  Local  Controller  will  maintain  a  separate  sequenced  stack  of  Flight  Progress  Strips  for 
each  departure  runway.  Actually,  there  is  a  single  vertical  rack  of  strips  separated  by  a 
runway  designator  strip  to  create  the  separate  queues.  As  an  aircraft  becomes  first  in  line,  it 
will  either  be  cleared  for  take-off  or  told  to  "taxi  into  position  and  hold"  and  subsequently 
cleared  for  take-off.  The  Local  Controller  must  separate  departing  and  arriving  aircraft  on 
the  same  and  crossing  runways.  The  Local  Controller  writes  the  departure  time  on  the 
Flight  Progress  Strip  as  the  aircraft  is  cleared  for  take-off.  The  strip  is  repositioned  on  the 
vertical  rack  below  a  separator  strip  designating  departed  aircraft.  The  last  three  or  four 
aircraft  that  have  departed  are  kept  in  this  position.  The  strips  are  removed  approximately 
three  or  four  minutes  after  departure. 

4.4. 1.6  HandofftoTRACON 

After  take-off,  the  departed  aircraft  is  instructed  to  contact  Boston  departure  on  the 
appropriate  frequency.  The  Flight  Progress  Strip  is  removed  from  the  rack  in  front  of  the 
Local  Controller  after  a  few  minutes  and  the  plastic  holder  tossed  in  a  bin  for  reuse.  The 
Flight  Progress  Strip  is  collected  by  the  Flight  Data  position  and  stored  in  a  box  by 
category  of  flight  such  as  commuter,  airliner,  etc. 

4.4.2  Arriving 

Arriving  aircraft  also  follow  a  sequence  as  do  their  Flight  Progress  Strips  although 
in  this  case  the  strips  are  handwritten  "short"  strips  and  the  data  is  taken  from  the  BRITE 
display  of  the  ARTS  data.  The  process  is  illustrated  in  Figure  6  and  discussed  below. 

4.4.2. 1  In  Boston  TRACON  Airspace 

Aircraft  are  handed  off  from  Boston  Center  to  Boston  approach  at  metering  fixes. 
Boston  TRACON  knows  the  airport  configuration  (active  runways)  and  vectors  traffic 
according  to  precoordinated  arrival  tracks,  merging  streams  of  traffic  as  necessary. 

Right  Progress  Strip  data  for  arriving  aircraft  is  available  in  the  Host  computer  at 
Boston  ARTCC.  The  ARTS  computer  at  Boston  has  a  patch  that  prints  the  destination 
airport  in  the  data  tag  for  arriving  aircraft;  (actually,  aircraft  arriving  at  Logan  contain  no 
tag,  aircraft  arriving  at  satellite  airports  contain  three  letter  tags).  For  this  reason,  Boston 
TRACON  does  not  need  the  Flight  Progress  Strips  and  does  not  print  them  out  at  the  FDIO 
printer  for  arrival  aircraft  although  strips  for  arrivals  at  satellite  airports  are  printed  and 
given  to  the  satellite  controller  as  an  extra  aid  in  keeping  track  of  traffic.  Right  Progress 
Strips  are  of  less  importance  for  arrivals  because  future  routing  is  of  no  concern;  the  aircraft 
are  handed  off  from  the  Boston  Center  at  coordinated  fixes,  the  destination  and  aircraft  type 
information  is  on  the  data  tag,  and  it  is  known  that  the  aircraft  intends  to  land. 

4.4.2.2  Local  Handoff 

The  Local  Controller  is  assisted  by  the  Local  2  position  who  hand  writes  data  on 
arrival  aircraft  on  blank  strips  that  are  shorter  than  the  normal  Flight  Progress  Strips. 
Typically,  the  only  information  recorded  is  the  aircraft  identification  and  an  "H"  with  a 
circle  to  signify  aircraft  in  the  "heavy"  category  or  a  "T"  to  signify  VFR  traffic.  If  the 
aircraft  is  landing  on  a  secondary  runway,  that  will  also  be  noted.  The  ARTS  display, 
including  aircraft  data  tags,  is  available  in  the  Tower  Cab  so  that  the  Local  controller  can 
monitor  aircraft  that  are  being  sequenced  by  the  TRACON.  The  data  is  tapped  off  of  the 
ARTS  and  is  displayed  on  a  special  monitor  in  the  Tower  Cab  known  as  the  Bright  Radar 
Tower  Equipment  (BRITE)  in  deference  to  the  high  amount  of  light  in  the  Cab.  This 
equipment  has  the  same  readout,  display  controls,  and  keypad  entry  device  that  are 
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available  at  radar  positions  in  the  TRACON.  Aircraft  are  told  when  to  contact  the  Tower  by 
Boston  Approach  Control  in  the  TRACON.  During  instrument  approaches,  this  is 
normally  at  the  outer  marker  when  the  aircraft  is  established  on  the  localizer  course 
inbound,  approximately  five  to  seven  miles  from  the  runway.  During  visual  meteorological 
conditions  (VMC),  the  aircraft  rnay  be  given  a  visual  approach,  but  the  flow  of  traffic  and 
the  handoff  to  the  Tower  Cab  is  essentially  the  same. 

4.4.23  Ground  Control  Handoff 

After  landing,  the  aircraft  is  told  to  turn  off  of  the  active  runway  and  contact 
Ground  Control.  The  handwritten  "short  strip"  is  passed  to  Ground  Control  position.  The 
pilot  contacts  Ground  Control  when  clear  of  the  runway  and  requests  taxi  clearance  to  a 
destination  on  the  airport.  The  Ground  Controller  clears  the  aircraft  via  a  route  of  letter 
coded  taxiways.  At  Boston,  the  Local  Controller  will  not  instruct  the  aircraft  to  contact 
Ground  Control  until  the  aircraft  has  cleared  all  active  runways,  i.e.,  if  the  aircraft  turns  off 
of  the  landing  runway  and  must  cross  another  runway  that  is  in  use,  the  Local  Controller 
will  instruct  the  aircraft  to  remain  on  his/her  frequency. 

4.4.2.4  Out-of-Movement  Area 

Ground  Control  is  responsible  for  the  safe  movement  of  the  aircraft  until  it 
transitions  out  of  the  movement  area  where  airline  personnel  will  direct  the  aircraft  into  the 
gate.  This  occurs  as  the  aircraft  cross  inside  the  truck  lines. 
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5.  SYSTEM  REQUIREMENTS 


The  overriding  requirement  for  the  Automatic  Strip  Management  System  (ASMS)  is 
that  it  perform  at  least  all  of  the  functions  of  the  current  manual  system  with  less  than  the 
current  workload  and  distraction  imposed  on  the  controller.  The  description  of  the  current 
system  in  the  first  section  of  this  requirements  document  therefore  becomes  an  integral  part 
of  the  ASMS  functional  requirements.  ASMS  must  be  the  electronic  equivalent  of  at  least 
the  system  described  in  section  4.  It  must  perform  all  of  the  services  described  in  section  4 
and  be  compatible  with  the  current  operation.  Any  acceptable  design  must  be  compatible 
with  current  outside  equipment,  procedures,  and  interfaces;  i.e.  ASMS  cannot  count  on 
changes  to  anything  else  in  order  to  satisfactorily  perform.  At  the  same  time,  a  successful 
ASMS  design  will  facilitate  and  accommodate  future  hardware  and  operational  changes  and 
will  be  designed  to  integrate  easily  with  future  systems  such  as  AAS,  TCCC,  TATCA, 
Mode  S,  and  ASTA. 

This  document  is  not  intended  to  be  a  design  requirements  document,  but  a 
description  of  the  functional  requirements.  It  is  necessary  at  times  to  illustrate  "types"  of 
designs  in  oruer  to  describe  functional  requirements  but  these  should  not  be  taken  as  design 
requirements.  Any  design  which  accomplishes  the  same  functions  will  be  considered. 
Indeed,  the  ASMS  program  will  of  necessity  involve  prototyping  of  hardware  and  software 
designs  and  controller  interfaces  to  test  system  acceptance  and  performance. 

5.1  HARDWARE  AND  INTERFACE  REQUIREMENTS 

The  initial  ASMS  design  must  integrate  with  the  current  system  of  flight  data 
information  flow  employed  at  Logan  airport.  This  involves  interfaces  primarily  with  the 
Host  computer  through  the  FDIO  and  the  ARTS  computer  and  display.  The  required 
interfaces  for  information  flow  are  illustrated  in  Figure  7.  The  interface  between  Logan  and 
the  "outside  world"  for  flight  strips  is  primarily  at  the  Flight  Data  positions  in  the  Tower 
Cab  and  TRACON. 

While  Figure  7  is  an  illustration  of  "information  interfaces,"  Figure  8  is  an 
illustration  of  hardware  and  hardware  interfaces  consistent  with  the  information  flow 
requirements.  The  system  envisioned  would  have  a  stand  alone  computer  (and  probably  a 
required  backup)  with  ten  separate  displays.  Each  of  the  displays  would  be  interchangeable 
and  each  display  would  be  capable  of  having  the  screen  customized  to  any  controller 
position  by  the  supervisor;  i.e.  the  supeivisor  could  decide  that  a  particular  screen  would  be 
the  Ground  Control  position.  Any  position  will  be  able  to  access  any  other  position's 
display  with  a  single  button  push  so  that  the  Local  position  could,  for  instance,  access  the 
Ground  Control  screen  by  pushing  one  button. 

The  ASMS  computer  must  be  capable  of  receiving  Flight  Progress  Strip  data  that 
currently  goes  to  the  FDIO  printer.  Any  installation  must  also  allow  flight  plans  to  be  filed 
from  the  Flight  Data  position  to  the  Host,  replacing,  emulating,  or  interfacing  with  the 
current  Wespercorp  FDIO  equipment  The  ASMS  software  should  provide  a  "buffer" 
between  the  Flight  Data  position  and  the  Host  allowing  the  position  to  continue  with  his  or 
her  Flight  Progress  Strip  work  while  ASMS  interacts  and  waits  for  the  HOST  in  requesting 
and  filing  flight  plans.  The  tap  into  the  TATCA  interface  may  be  desirable  if  there  is 
additional  useful  information  that  can  be  gained  from  the  Host  but  the  FDIO  interface  is  still 
required  because  ASMS  must  be  able  to  enter  and  amend  flight  plans  (send  information  into 
the  Host  emulating  the  FDIO)  and  the  hardware  design  should  be  capable  of  being 
introduced  at  other  Towers  that  may  not  have  a  TATCA  interface. 
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Figure  7.  Current  Interfaces  for  Flight  Data  Information  Flow  for  Flights  into  or  out  of  Boston  Logan 
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Figure  8.  ASMS  Interface  Requirements 


An  interface  with  the  ARTS  computer  is  required  to  obtain  data  on  arriving  aircraft 
Data  on  arrival  aircraft  is  needed  to  replace  the  current  procedure  of  writing  "short  strips" 
by  hand  based  on  data  from  the  BRTTE  display  and  because  it  is  required  in  order  to 
display  the  interaction  between  arriving  and  departing  aircraft  needed  by  the  Local 
controller  display.  ASMS  will  have  to  emulate  the  ARTS  keypad  for  entering  data  block 
information  and  therefore  interface  direcdy  with  the  ARTS  in  a  manner  similar  to  the 
existing  BRITE/ARTS  keypad  connection  to  the  Tower  Cab. 

ASMS  must  be  designed  to  accommodate  possible  future  interfaces  with  additional 
airport  equipment  and  status  displays  including  the  Airport  Information  Distribution  System 
(AIDS),  the  Low  Level  Wind  Shear  Alert  System  (LLWAS),  Automatic  Weather 
Observing  System  (AWOS),  Automatic  Terminal  Information  System  (ATIS),  Systems 
Atlanta  Information  Display  (SAIDS)  computer,  Digital  Alimentary  Setting  Indicator 
(DASI),  airport  configuration  input,  runway  visual  range  (RVR)  measuring  equipment, 
runway  lighting  status,  and  the  computer  generated  airport  users  interface  line  which 
provides  general  information  between  the  airport  operator  and  user,  etc.  The  use  of  this 
information  by  ASMS  will  depend  on  the  design  of  ASTA  and  TCCC  and  their  interface 
with  ASMS  as  well  as  possible  stand  alone  functions  that  might  be  performed  by  ASMS  at 
towers  that  might  not  have  ASTA  or  TCCC. 

The  question  of  controller  interaction  devices  will  be  addressed  during  the 
prototyping  phase  of  ASMS  but  Figure  8  illustrates  keyboards  at  the  Supervisor's  and 
Flight  Data's  positions  in  recognition  of  the  more  extensive  inputs  required  by  these 
positions. 

5.2.  SCREEN  DESIGN  REQUIREMENTS 

This  section  describes  the  requirements  for  screen  design  by  position.  Figures  9a-e 
at  the  end  of  this  section  are  sample  illustrations  of  screens  to  aid  in  following  the 
descriptions.  In  these  samples  it  is  assumed  that  "windows"  will  be  used  that  can  be 
opened  and  closed  by  "clicking"  on  the  appropriate  highlighted  section  of  a  screen  or  from 
menus  as  appropriate.  It  is  also  assumed  that  some  form  of  single  button  clicking  will 
transfer  information  from  one  position  display  to  the  next  as  the  "strip"  progresses  through 
the  Tower.  The  actual  screen  designs  and  best  methods  of  displaying  information  will  be 
refined  in  the  prototyping  and  testing  phases. 

5.2. 1  Supervisor 

The  supervisor's  position  and  display  will  allow  access  to  all  information  and 
displays.  It  will  have  the  capability  of  reconfiguring  the  entire  system  so  that  any  physical 
screen  can  act  to  support  any  controller  position.  Tbe  supervisor  will  also  be  able  to 
combine  positions  which  would  cause  a  position  display  to  have  the  capability  of  alternately 
acting  as  more  than  one  position.  The  supervisor's  position  will  also  be  used  to  input  any 
adjustable  parameters  such  as  how  far  ahead  of  time  (prior  to  departure)  an  aircraft  ID  will 
enter  the  queue  at  the  Flight  Data  position. 

The  supervisor's  position  will  be  used  to  order  the  standardized  traffic  data  reports 
and  controller  time  data  and  eligibility  reports. 
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These  uses  suggest  a  menu  driven  multiple  screen  approach  with  a  keyboard.  The 
supervisor  does  not  need  to  be  looking  out  of  the  Tower  Cab  while  selecting  and  ordering  a 
weekly  traffic  data  report  so  the  interface  can  be  one  that  requires  more  direct  interaction 
and  attention  to  the  system  and  display.  There  should  be  one  supervisor’s  terminal  in  the 
Tower  Cab  and  one  in  the  TRACON  and  they  should  be  identical. 

5.2.2  Flight  Data 

The  requirements  for  the  Right  Data  position  terminal  are  illustrated  in  Figure  9a. 
There  should  be  a  queue  displayed  of  Flight  Strips  that  are  received  from  the  Host.  The 
queue  should  contain  the  aircraft  ID,  three  letter  destination  code,  and  proposed  departure 
time  in  UTC  (Zulu).  The  queue  should  be  sorted  by  order  received,  last  in  at  the  top. 

There  should  be  controller  preference  options  to  resort  the  queue  by  category 
(air  carrier,  commuter,  general  aviation)  and/or  alphabetically.  The  Flight  Data 
controller's  normal  mode  of  operation  will  be  to  select  (highlight)  the  aircraft  at  the  bottom 
of  the  queue  which  will  generate  a  window  display  of  a  Flight  Progress  Strip.  The  Right 
Data  position  will  examine  the  strip  for  correctness,  especially  for  compliance  of  the  routing 
with  the  "East  Coast  Plan."  The  ASMS  software  should  incorporate  an  automatic  alert  and 
display  of  the  final  destination  if  it  is  one  of  the  destinations  listed  on  the  SAIDS  as  having 
ESP  or  EDCT  delays.  The  controller  will  coordinate  with  TMU  to  check  on  gate  holds  and 
release  times  and  will  move  a  cursor  to  the  appropriate  box  on  the  Flight  Progress  Strip 
display  and  enter  the  release  time.  When  the  controller  is  finished  with  the  Right  Progress 
Strip  he  or  she  will  send  it  to  the  Clearance  Delivery  display  with  the  push  of  a  button  or 
the  click  of  a  mouse. 

If  there  are  any  changes  to  the  flight  plan,  such  as  routing  or  changing  the  flight 
plan  from  IFR  to  VFR,  it  will  be  necessary  for  the  controller  to  interact  with  the  Host  The 
controller  should  have  the  option  of  selecting  the  current  Flight  Progress  Strip  and 
requesting  a  display  for  entering  changes  that  will  be  incorporated  in  the  Host’s  flight  plan. 
The  illustration  in  Figure  9a  shows  a  Right  Plan  form  window  but  it  may  be  more 
appropriate  to  abbreviate  the  window  to  a  different  form.  In  any  event,  the  controller 
should  be  able  to  enter  amendments  by  moving  a  cursor  to  the  needed  area  and  typing  in  the 
change.  The  interaction  with  the  Host  should  be  transparent  to  the  controller,  that  is  the 
changes  should  be  stored  by  ASMS  and  ASMS  should  "negotiate"  with  the  Host  and 
simply  inform  the  controller  that  the  amendments  have  been  accepted  by  the  Host  An  icon 
should  indicate  that  the  change  is  pending  or  accepted  so  that  the  controller  can  proceed 
with  other  work.  In  no  case  should  the  system  "hang-up"  while  waiting  to  receive  a 
response  from  the  Host. 

The  controller  should  also  be  able  to  access  the  flight  plan  data  stored  in  the  Host 
for  any  aircraft  ID  in  the  queue  or  by  typing  in  the  aircraft  ID  directly.  In  the  event  an 
aircraft  calls  Clearance  Delivery  for  a  clearance  and  there  is  no  record  for  that  aircraft  in 
ASMS,  the  Flight  Data  position  should  be  able  to  query  the  Host  through  ASMS  for  any 
information  the  Host  has  on  that  flight  This  capability  currently  exists  so  there  is  no 
software  change  required  in  the  Host .  However,  the  current  system  is  not  user  friendly 
and  the  ASMS  software  should  provide  that  user  friendly  buffer  insulating  the  controller 
from  detailed  entry  requirements  of  the  Host  software. 

Finally,  the  Flight  Data  position  must  have  the  ability  to  enter  a  flight  plan  directly 
into  the  Host  using  the  Right  Plan  form  window.  This  would  be  similar  to  the  procedure 
used  to  amend  a  flight  plan  using  a  form  and  cursor  and  typing  the  information  in  from  a 
keyboard. 
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5.2.3  Clearance  Delivery 


The  Clearance  Delivery  screen,  as  illustrated  in  Figure  9b,  should  have  separate 
queues  for  air  carriers,  commuters,  and  general  aviation  aircraft  and  each  queue  should  be 
sorted  alphabetically  to  facilitate  finding  and  highlighting  the  flight  when  the  clearance  is 
requested  by  the  aircraft.  The  queue  listing  should  include  the  aircraft  ID  (flight  number), 
three  letter  destination  code,  and  proposed  departure  time.  The  controller  should  have  the 
ability  to  produce  a  window  with  the  Flight  Progress  Strip  format  by  highlighting  an 
aircraft  in  a  queue.  The  controller  should  also  be  able  to  create  a  window  with  a  format 
customized  to  the  clearance  sequence.  The  clearance  sequence  is  1)  destination,  2)  initial 
routing  (runway  heading,  initial  heading,  vectors  etc.)  3)  en  route  routing  (may  be  cleared 
as  filed),  4)  initial  altitude,  5)  further  altitude  clearance  and  time  or  distance  to  expect  that 
clearance,  6)  radar  beacon  code,  and  7)  departure  control  frequency.  A  sample  clearance 
delivery  window  with  clearance  is  illustrated  in  Figure  9b 

When  an  aircraft  calls  for  clearance  on  the  clearance  delivery  frequency,  the 
controller  will  select  and  highlight  the  flight  producing  the  clearance  window.  After 
reading  and  verifying  the  clearance,  a  cursor  will  prompt  the  controller  to  enter  a 
verification  code  signaling  ASMS  that  the  clearance  has  been  received  and  read  back  by  the 
flight  crew.  Additionally,  cursors  should  prompt  for  gate  and  ATIS  information  codes  if 
they  are  know.  Alternately,  the  controller  should  be  able  to  enter  these  codes  in  the  Flight 
Progress  Strip  form  window.  A  single  button  selection  of  the  flight  displayed  in  the  Flight 
Progress  Strip  window  or  clearance  window  will  signal  ASMS  that  after  checking  for 
clearance  verification  the  strip  should  go  to  the  Ground  Control  position. 

5.2.4  Boston  Gate 

The  Boston  Gate  display  will  receive  "strips"  from  the  Clearance  Delivery  position. 
There  should  be  queues  for  each  category  (air  carrier,  commuter,  and  general  aviation)  of 
flight  as  illustrated  in  Figure  9c.  The  queues  should  contain  the  aircraft  ID  (flight  number), 
aircraft  type,  gate,  and  initial  departure  fix  and  be  sorted  by  first  come  first  served  with  the 
latest  entry  at  the  top  and  the  oldest  entry  at  the  bottom.  Boston  Logan  uses  three  letter 
designators  for  local  use  to  depict  departure  fixes.  The  VOR  fixes,  such  as  Manchester, 
use  the  official  three  letter  designator  (MHT)  that  is  recognized  throughout  the  system  but 
the  intersection  fixes,  such  as  BOSOX,  which  require  five  letters,  are  abbreviated  to  three 
letters  (BOX)  for  local  Boston  use. 

The  Boston  Gate  position  will  require  the  capability  of  displaying  the  flights  in  first 
come  first  served  order  by  departure  fix  as  illustrated  in  Figure  9c.  Multiple  windows  with 
different  departure  fixes  should  be  allowed.  This  is  because  Boston  Gate  needs  to  be  able 
to  supply  aircraft  to  Ground  by  departure  fix  on  a  first  come  first  served  basis.  Boston 
Gate  should,  as  with  all  displays,  have  the  capability  to  select  an  aircraft  in  any  queue  and 
display  the  Flight  Progress  Strip  in  a  window.  A  cursor  prompt  will  allow  Boston  Gate  to 
enter  the  assigned  runway.  The  position  should  also  have  the  capability  to  update  any 
information  in  the  notation  boxes  on  the  Flight  Progress  Strip  using  the  same  input 
procedures  as  the  other  positions. 
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'S  Clearance  Delivery  Screen 


5.2.5  Ground  Control 


The  Ground  Control  position  has  a  complex  set  of  requirements.  It  is  the  Ground 
Control  position  that  authorizes  "push  back"  from  the  gate  so  there  is  a  requirement  to 
know  which  aircraft  are  at  which  gates,  in  the  order  that  they  called  ready  to  push.  It  is 
also  necessary  to  know  from  what  runway  an  aircraft  will  depart  and  its  initial  departure  fix 
so  that  the  queueing  order  for  a  particular  runway  will  not  impose  additional  separation 
delays  by  having  aircraft  with  the  same  departure  fix  lined  up  in  order.  There  are  three 
stages  of  interest  to  the  Ground  Control  position  for  departing  aircraft.  First,  the  aircraft  at 
the  gate  awaiting  clearance  for  push  back  in  roughly  the  order  in  which  they  called. 

Second,  aircraft  taxing  out  to  the  departure  mnway  still  under  control  of  Ground.  And 
third,  aircraft  in  a  queue  at  the  departure  end  of  the  runway  that  need  to  be  transferred  to  the 
Local  Controller’s  display.  Additionally,  C  ^und  Control  is  concerned  with  arriving 
aircraft  being  handed  off  from  Local  as  they  clear  the  active  runways.  The  duties  of  the 
Ground  Control  position  require  that  he  or  she  be  looking  outside  almost  all  of  the  time. 
This  combination  of  requirements  makes  the  Ground  Control  display  one  of  the  most 
challenging. 

Figure  9d  illustrates  the  complex  combination  of  data  that  must  be  displayed  to  the 
Ground  Controller.  In  this  example,  a  runway  diagram  is  included  in  the  center  of  the 
screen  to  provide  an  orientation.  The  primary  queueing  displays  are  sorted  by  departure 
runway  with  bars  separating  the  aircraft  that  are  at  the  gate  from  those  taxing,  and  those 
awaiting  take-off  at  the  end  of  the  runway.  Optional  windows  are  available  to  sort  the 
departures  by  initial  departure  fix  noting  the  departure  runway.  In  the  example.  Delta  1 10, 
still  taxiing,  is  departing  runway  4R  bound  for  Manchester  VOR  as  the  initial  departure  fix. 
The  next  aircraft  using  Manchester  will  be  GAA  508  departing  on  runway  9.  GAA  508  is 
still  taxing  out  to  runway  9  where  there  is  a  queue  of  AJC  169  and  Eastern  1 101  ahead 
awaiting  departure.  In  this  example.  United  135,  a  DC10,  is  departing  via  Manchester  and 
is  ready  for  takeoff  but  is  using  runway  15R,  probably  because  it  needs  the  longer  length. 
According  to  the  Manchester  initial  departure  fix  queue,  however.  United  135  is  fifth  in  line 
for  Manchester.  Depending  on  the  traffic,  he  may  be  cleared  early  since  no  other 
Manchester  traffic  is  ready  to  go.  Delta  1021,  a  Boeing  727,  has  just  arrived  and  turned  off 
of  runway  9  and  will  be  taxing  to  gate  30. 

Aircraft  at  the  gate  ready  for  taxi  are  input  into  the  display  queue  by  Boston  Gate. 
When  the  aircraft  is  cleared  for  push  back  by  Ground  Control  he  or  she  will  adjust  the  bar 
that  divides  the  "at  gate"  aircraft  from  the  taxing  aircraft.  Ground  will  also  adjust  the  bar 
when  the  aircraft  is  in  the  departure  queue  at  the  end  of  the  runway.  So,  as  Delta  1 10,  a 
Boeing  767,  approaches  the  departure  queue  for  runway  4R,  the  Ground  Controller  will 
"slide"  the  bar  below  Delta  1 10  in  the  runway  4R  queue  display.  This  action  will 
automatically  including  the  aircraft  on  the  Local  display. 

The  interface  should  allow  the  selecting  of  any  aircraft  for  display  of  the  Flight 
Progress  Strip  as  illustrated.  The  Ground  Controller  should  also  have  the  capability  to 
reorder  aircraft  in  a  queue.  It  is  anticipated  that  the  Ground  Control  display  will  offer 
options  to  tailor  the  display  for  individual  preferences. 
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’S  Ground  Control  Screen 


5.2.6  Local  Control  (Tower) 


The  Local  Controller  is  concerned  with  the  efficient,  coordinated  use  of  multiple 
runways  by  arrival  and  departure  aircraft.  The  primary  information  needed  is  the  aircraft 
ID,  type,  beacon  code,  and,  for  departing  aircraft,  initial  departure  fix.  The  display 
illustrated  in  Figure  9e  is  oriented  around  the  airport  runway  diagram  and  includes  queues 
for  departure  aircraft  by  runway  and  displays  of  arriving  aircraft  with  data  block 
information  taken  from  the  ARTS  display. 

The  presumption  is  that  Local  will  have  little  or  no  time  for  interaction  with  the 
ASMS  display.  Currently,  a  Local  2  position  aids  the  Local  Controller  at  all  times  and  will 
operate  the  display.  A  moving  bar  will  separate  the  departing  aircraft  that  are  coming  under 
the  control  of  TRACON  from  the  aircraft  in  queue  awaiting  departure.  The  aircraft  in  the 
runway  queue  appear  as  Ground  Control  slides  the  bar  on  his  ex'  her  display  to  indicate  that 
the  aircraft  is  now  in  the  departure  queue.  The  aircraft  does  not  contact  the  Tower  but 
monitors  the  Tower  frequency  and  the  Local  Controller  will  use  the  displayed  queue  to 
identify  the  aircraft  ID  as  they  become  number  one  for  departure.  This  is  the  procedure 
used  today  with  the  manual  Flight  Progress  Strips.  The  only  required  input  by  the  Local 
(or  Local  2)  is  to  move  a  bar  to  indicate  that  an  aircraft  is  departing  a  runway  or  push  a 
button  to  switch  an  arriving  aircraft's  "short  strip"  (based  on  the  ARTS  data  block)  to  the 
Ground  Control  display. 

5.2.7  Helicopter/TCA 

The  helicopter/TCA  position  will  require  a  modified  Local  display  to  accommodate 
extensive  VFR  departures  as  well  as  the  ARTS  generated  short  strips  for  arrivals. 

5.2.8  TRACON 

The  display  in  the  TRACON  will  be  identical  to  the  Local  display  illustrated  in 
Figure  9e  and  will  require  no  input  or  interaction  by  the  controller. 

5.3  HUMAN  FACTORS  REQUIREMENTS 

It  is  clear  that  the  design  of  the  interface  between  the  controller  and  ASMS  will  be 
the  key  challenge  in  the  design  of  any  ASMS  system.  It  is  not  the  intention  of  this 
document  to  solve  the  man/machine  interface  problems  or  dictate  a  specific  design.  The 
approach  taken  is  to  point  out  the  functional  requirements  as  is  done  in  Sections  4  and  5.2 
and  leave  the  details  of  design  implementation  to  the  prototype  phase  of  the  program. 

However,  there  are  certain  features  or  requirements  that  can  be  discussed  at  this 
stage.  The  presumption  has  been  that  there  will  be  some  kind  of  CRT  display  technology 
employed  and  that  it  will  be  incorporated  in  the  shelf  areas  in  the  Tower  Cab  where  the 
flight  strip  racks  are  now  located.  The  space  required  by  the  displays  should  be  no  larger 
than  that  now  required  by  the  flight  strip  racks  and  the  displays  should  be  as  easy  to  read  as 
are  physical  flight  strips.  This  will  require  some  advanced  display  technology  because  of 
the  varying  light  conditions  in  the  Tower  Cab  and  because  of  the  requirement  for  the 
controllers  to  look  outside.  At  the  very  simplest  level,  the  displays  could  be  used  to 
"replace"  the  flight  strips  now  mounted  in  racks  but  it  seems  clear  from  the  discussions  of 
the  current  use  of  flight  strips  in  Section  4  that  "customizing"  the  display  by  position  is 
desirable.  One  approach  is  to  use  "windows"  as  is  illustrated  in  Figures  9a-e.  The 
windows  can  be  customized  to  offer  many  alternate  displays  of  the  data  and  the  display  can 
be  "controlled"  by  the  controller. 
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rS  LocallTRACON  Screen 


The  human  factors  requirements  on  input  vary  greatly  by  position.  The  Flight  Data, 
Clearance  Delivery  and  Gate  positions  can  pay  more  attention  to  the  CRT  screen  and  have  a 
greater  requirement  to  interact  than  the  Ground  Control  or  Local  positions.  The  Ground 
Control  and  Local  positions  must  devote  most  of  their  attention  outside.  Therefore,  input 
devices  that  employ  cursors,  a  mouse,  menus,  and  a  keyboard  may  be  perfectly  acceptable 
to  the  Flight  Data  position  which  must  have  the  capability  of  entering  a  flight  plan,  but 
would  be  unacceptable  to  the  Local  Controller  who  inputs  little  or  nothing  and  must  be 
looking  outside. 

Some  CRT  display  input  and  control  devices  should  be  common  to  all  positions. 
For  instance,  a  keypad  or  push  buttons  that  allow  selection  and  display  of  another  position 
should  be  common  to  all  positions.  It  is  important  to  remember  that  the  controllers  change 
position  on  a  regular  basis  and  that  most  controllers  are  checked  out  and  current  at  more 
than  one  position.  Therefore  it  is  important  that  the  different  ASMS  positions  incorporate 
common  input/output  methods.  If  a  series  of  buttons  across  the  top  of  the  display  are  used 
to  select  the  position  display  (Ground,  Gate,  etc.),  then  that  should  be  common  to  all 
CRTs. 


Each  position  follows  a  repeatable  sequence  of  events  with  each  aircraft  most  of  the 
time.  Therefore,  it  seems  reasonable  to  design  an  interaction  system  that  requires  the  least 
input  for  a  "normal"  sequence.  This  "next  logical  sequence"  (NLS)  approach  will  allow  a 
controller  to  process  the  selected  aircraft  to  its  next  stage  with  the  single  click  of  a  button. 
For  instance,  after  Clearance  Delivery  reads  a  clearance  and  monitors  the  readback  for  an 
aircraft,  a  single  button  click  should  remove  that  aircraft  from  the  Clearance  Delivery 
display,  close  all  open  windows,  indicate  verification  of  the  readback  to  the  ASMS 
computer,  and  send  the  strip  to  Boston  Gate.  This  NLS  approach  can  be  incorporated  in 
queue  displays  so  that  the  next  logical  aircraft  in  sequence  is  automatically  selected  or 
highlighted  for  selection. 

The  answers  to  the  most  acceptable  interaction  devices,  designs,  and  hardware  will 
be  found  during  the  prototype  testing  phase. 

5.4  DATA  BASE  REQUIREMENTS 

5.4.1  Archival  and  Retrieval  Requirements 

The  Flight  Progress  Strip  images  that  progress  through  the  ASMS  system  should 
be  stored  on  line  for  at  least  48  hours  and  should  be  automatically  stored  off  line  on  a  real 
time  basis.  The  off  line  storage  device  should  be  capable  of  storing  at  least  one  weeks 
worth  of  Flight  Progress  Strip  images  and  have  small  inexpensive  removeable  cartridges  or 
disks  that  would  allow  indefinite  storage  of  data.  The  Flight  Progress  Strip  images  that  are 
stored  should  be  time  marked  by  ASMS  by  position  and  include  all  data  input  by  the 
controllers.  These  should  also  include  the  "short  strips"  taken  from  the  ARTS  computer 
data  blocks  and  generated  by  ASMS. 

Menu  driven  software,  accessible  at  the  supervisor's  terminal,  should  allow  the 
supervisor  to  search  through  the  on  line  or  off  line  data  base  of  stored  Flight  Strip  images 
to  find  Flight  Strips  that  meet  the  search  criteria.  The  search  criteria  should  include  at  least 
aircraft  ID,  time  period,  beacon  code,  initial  departure  fix,  routing  arrival  or  departure 
runway  and  type.  The  search  software  should  allow  for  input  of  multiple  search  criteria, 
i.e.  the  program  should  be  able  to  find  all  American  Airlines  Boeing  727s  that  departed  on 
runway  4L  between  1400Z  and  1600Z. 
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5.4.2  Traffic  Data  Recording  Requirements 

Using  the  on  and  off  line  data  base  storage  system  described  above,  ASMS  should 
offer  a  menu  driven  software  system  accessible  to  the  supervisor  to  generate  traffic  data 
summary  reports.  The  system  should  be  capable  of  summarizing  the  data  by:  1)  arrivals 
and  departures;  2)  aircraft  category  (heavy,  large,  small)  or  (air  carrier,  commuter,  general 
aviation);  3)  runway  used;  4)  time  period.  Standardized  report  formats  and  parameters 
should  be  stored  so  that  the  supervisor  can  select  a  standard  report  from  a  menu. 

5.4.3  Operational  Recording  and  Eligibility  Requirements 

The  ASMS  system  should  keep  track  of  the  acting  controller  by  position  by 
requiring  a  log-in.  The  log-in  should  allow  the  recording  of  training  time  by  trainer  and 
trainee.  This  data  should  be  stored  with  the  Flight  Progress  Strip  data.  A  menu  driven 
software  package  should  be  provided  that  allows  the  supervisor  to  prepare  standardized 
summary  time  reports  including  training  and  overtime.  The  system  should  provide  the 
supervisor  with  real  time  eligibility  checks  which  includes  algorithms  for  position 
certification,  training,  length  of  time  at  position,  or  any  other  constraint  that  would 
determine  a  persons  eligibility  to  act  as  a  controller  at  that  position.  In  no  case  should  the 
ASMS  software  prevent  a  controller  from  logging  in,  even  if  it  violates  a  preset  constraint. 

5.5  OPTIMUM  QUEUE  MODULE 

ASMS  will  have  access  to  data  on  departing  aircraft  by  gate,  aircraft  type,  and 
routing  including  initial  departure  fix.  It  is  possible  that  a  knowledge  based  algorithm 
could  be  developed  to  optimize  the  departure  sequence  by  runway  taking  into  account 
arrivals  (both  known  from  ARTS  or  Host  or  predicted  based  on  statistics),  airport 
configuration,  separation  standards,  flow  control  limits  to  initial  departure  fixes,  and 
aircraft  performance  limits.  The  software  design  should  at  least  make  provisions  for  a 
software  module  designed  to  optimize  departure  queues.  This  could  serve  as  a  test  bed  for 
future  ASTA  software  and  for  integration  with  TATCA. 


41 


